![[Elastic Beanstalk] アプリケーションのクローンを作ってEC2性能を比較してみた](https://devio2023-media.developers.io/wp-content/uploads/2014/05/Elastic_Beanstalk.png)
[Elastic Beanstalk] アプリケーションのクローンを作ってEC2性能を比較してみた
はじめに
AWSチームのすずきです。
AWS Elastic Beanstalk、AWS クラウド内でのアプリケーションのデプロイと管理を簡単に実現するサービスとして提供されています。
今回、このElastic Beanstalkの機能を利用してEC2インスタンスタイプを変更したクローン環境を作成し、EC2のスペック検討を試みる機会がありましたので紹介させて頂きます。
参考 （AWS 公式ドキュメント）
作業手順
クローンの作成
- AWSコンソールを開き、Elastic Beanstalk のダッシュボード画面よりクローン元となるアプリケーション環境を指定します。
*「アクション」より、「環境のクローンの作成」を指定します。
- 新しい環境として起動するクローン環境の「環境名」と「環境URL」を指定し、「クローン」を指定します。
- Elastic Beanstalk用に提供されるプラットフォーム（AMI）、そのアップデートを同時に行うことも可能です。
- クローン環境の作成が始まります。
- 進捗はイベント画面で確認できます。
- EC2のインスタンスが数台、複雑なプロビジョニングが実施されない環境であれば、15分程度で起動完了となります。
- 作成時に指定した「環境URL」＋「elasticbeanstalk.com」により、クローン環境の動作が確認可能です。
クローンの変更
- 今回、クローン環境のEC2インスタンスタイプを「t2」→「m3」→「c4」とする変更を試みました。
-
Elastic Beanstalk のダッシュボード画面より、「設定」から「インスタンス」の設定画面を開きます。
- インスタンスタイプを任意のものに変更し「適用」します。
- 確認画面で「保存」とすると、インスタンスタイプの変更が開始します。
- Elastic Beanstalk のデフォルト設定では、CloudFormationのローリングアップデート機能により、EC2インスタンスの変更は1台づつ行われます。
環境の入替
- 設定変更が完了したクローン環境について正常動作を確認した後、DNS切替（CNAMEスワップ）によるオリジナル環境との入替えを実施します。
-
Elastic Beanstalk のダッシュボード画面より、「アクション」から「環境URLのスワップ」の設定画面を開きます。
- 環境URLのスワップ画面で、オリジナル環境の「環境名」を選択し、「スワップ」を指定すると、 「elasticbeanstalk.com」ドメインの環境URLが切り替ります。
- 環境URLに利用されるDNSレコードのTTLは60秒。双方の環境に数分間アクセスが発生する時間は存在します。
クローン環境の検証
- 入替を実施したクローン環境の評価を実施します。
- 今回、監視SaaSのNewRelicを利用して、PHPアプリケーションの平均レスポンスタイムと、CPU利用状況についてインスタンスタイプ毎の比較を実施しました。
アプリケーションレスポンスタイム
- t2.medium
- m3.medium
- c4.large
CPU利用状況
- t2.medium
- m3.medium
- c4.large
考察
m3.medium
- 「t2.medium」と比較し、アプリケーションレスポンスタイムの上昇（1400→2400ms）と、CPU使用率、ロードアベレージの上昇が確認されました。
- CPU使用率のSteal発生状況から、仮想基盤側のCPUリミッタが発動し、スループット低下に繋がっていると考えられました。
- 「m3.medium」インスタンスのオンデマンド費用は1時間あたり0.096$。CPU性能を必要とする当アプリケーション環境での利用は不向きと判断できました。
c4.large
- 「t2.medium」と比較して、アプリケーションレスポンスタイムは（1400→900ms）と改善が確認されました。
- 1時間あたりのEC2インスタンス単価の上昇（0.08$→0.14$）に相当する改善ですが、現時点では過剰な性能と考えられました。
- 当面「t2.medium」のインスタンスをCPU性能のバーストが効き続ける（CPUクレジットが枯渇しない）範囲で利用し、 スポット性能の確保は、スケールアウト（t2.medium台数の追加）で実施する事としました。
- 今後、アプリケーション負荷の増大や、性能の安定性が求められた場合には「c4」への切替が適切と判断しました。
クローン環境の切り戻し
- Elastic Beanstalk のダッシュボード画面より、「アクション」から「環境URLのスワップ」の設定画面を開き、再度アプリケーション環境の入替えを実施します。
クローン環境の撤去
- 切り戻し後のクローン環境へのアクセスが収束した事を確認して「環境の終了」を実施する事で、クローン環境のEC2やELBなどのリソースが撤去されます。
まとめ
Elastic Beanstalk 上で管理されたアプリケーションは、このようにアプリケーション環境の追加、切替、削除を非常に簡単に実施する事が可能となります。
今回はインフラ基盤のスペック変更、実アプリケーション環境で安全に実施できる事を確認できましたが、 アプリケーションのバージョンアップやOSやミドルウェアのアップデートの際にも、Elastic Beanstalkによる検証環境の展開は有効と考えられます。
導入後のアプリケーション環境の管理が劇的に楽になるElastic Beanstalk、是非お試しください。
